1. Field of the Invention
This invention relates to on-line network communication systems and, more particularly, to a system for performing remote requests over a wide area network.
2. Background
A common example of network communications is a plurality of personal computers communicating over a network with a remotely located file server. In such systems, the personal computers are called clients and the file server is called a server. The clients access data on the server by sending requests to the server, which carries out the work and sends back the replies. This model is typically referred to as the client-server model.
In the client-server model, communication takes the form of request-response pairs. Conceptually, the request and the response is similar to a program calling a procedure and getting a result. In such cases, the requester initiates an action and waits until the results are available. Ordinarily, when a program calls a local procedure, the procedure runs on the same machine as the program. With a remote procedure call, however, the remote procedure runs on the remotely located server. In order to standardize remote client-server requests, the computer industry has implemented the Remote Procedure Call (RPC).
In conventional systems, remote procedure calls act as if they execute locally. The programmer developing an application invokes a remote procedure just like local procedure calls. Consequently, an application programmer does not need to write software to transmit computational or Input/Output-related requests across a network, to handle network protocols and to deal with network errors. Remote procedure calls handle such tasks automatically.
Conventional remote procedure calls operate within the network architecture connecting the client with the server. In general, networks are organized as a series of layers or levels as defined by the International Standards Organization (ISO) Open Systems Interconnection (OSI) Reference Model. The OSI reference model contains seven layers which are called the application layer, the presentation, layer, the session layer, the transport layer, the network layer, the data link layer and the physical layer.
In most systems, a library of the remote procedure calls are created and provided to an application programmer. Typically, the remote procedure calls are software routines which the application uses at run time. During the development of an application, the application programmer writes the application software code which contains references to the remote procedure calls. As an application program runs, it invokes a remote procedure call in the dynamic link library and passes a number of parameters to the invoked remote procedure call.
Once invoked, the remote procedure call receives the parameters and marshals them for transmission across the network. Marshaling parameters means ordering them and packaging them in a particular way to suit a network link. In addition, the remote procedure call locates the proper remote computer which executes the remote procedure call, determines the proper transport mechanisms, creates a network message and sends the message to the network transport software. Furthermore, the remote procedure call deals with network errors which may occur and waits for results from the remote server.
When the remote procedure call arrives at the server, the transport layer passes it to the remote procedure calls running on the server. The remote procedure call on the server then unmarshalls the parameters, reconstructs the original procedure call and directs the server to complete the actions requested by the client. After the server has completed its work, the remote procedure call running on the server sends the results back to the client in a similar manner.
While remote procedure calls operate efficiently on fast local area networks, they suffer from several disadvantages when implemented on wide area networks with slow speed communication lines. Local area networks typically transfer data at over ten Megabits per second. A wide area network with slow speed communication lines, on the other hand, typically transfers data over telephone lines via a modem at 28 Kilobits per second or less.
As explained above, conventional remote procedure calls do not return control to the application program until the server has completed a request. Consequently, the client application suspends operations until it receives a response from the server. This may result in substantial delays, for example, when a client application has requested the server to transfer a large block of data. Consequently, unless implemented in a complex multi-threaded manner, the client application waits for a response before the client application executes other remote procedure calls. As a result, the client application wastes processor cycles while waiting for a response from the server.
In many applications, users may request large amounts of data such as audio, multimedia, and large data files. While a remote procedure call allows the transfer of large blocks of data, a conventional remote procedure call fails to provide timely status information about such data transfers. Consequently, the client cannot query the server regarding the status of the requested information. Thus, a system may appear to "hang" when executing a remote procedure call over a wide area network connected by modems to telecommunication lines. Because users typically expect a high degree of user interaction, lack of status information over slower wide area networks means that many users will simply avoid requesting files with large amounts of data.
In addition, to implement remote procedure call systems in multitasking operating systems requires the use of complex multi-threading techniques. A multitasking operating system allows a single personal computer to work on more than one task at one time. For example, a personal computer with a Microsoft Windows operating system can simultaneously run a database program, a word processing program, a spreadsheet, etc.
For example, in a multi-threaded operating system a thread represents one of possibly many subtasks needed to accomplish a job. For example, when a user starts a database application, the operating system initiates a new process for the database application. Now suppose the user requests the generation of a payroll report from the database application. While this request is pending, the user enters another database request such as a request for an accounts receivable report. The operating system treats each request--the payroll report and the accounts receivable report--as separate threads within the database process.
Because conventional operating systems schedule threads for independent execution, both the payroll report and the accounts receivable report can proceed at the same time (concurrently). Accordingly, it is possible to generate multiple pending remote procedure calls by creating an execution thread for each remote procedure call. However, the implementation of a multi-threaded remote procedure call system is very complex and requires a high level of expertise about the operational details of the operating system.
Another deficiency of current remote procedure calls is that they do not allow an efficient cancellation of a pending request sent to a server. In many wide area network applications, a user may wish to download a large block of data and later wish to cancel the request. Over a wide area network, such transfers of large data blocks take a significant amount of time. Current remote procedure calls, however, do not allow the cancellation of pending remote procedure calls. As a result, current remote procedure calls can waste system resources on unwanted requests.
In addition, conventional remote procedure calls typically require the client to allocate enough memory space to hold an entire data block before requesting data from the server. In many multimedia applications, however, the client does not know the size of a data block before it requests the data block from the server. Therefore, in conventional systems, the client typically issues two requests prior to receiving a data block from the server. The first request directs the server to send the size of the data block. The client then uses the data block size to allocate enough memory to hold the data block. The second request then directs the server to download the data block. Two requests, however, increase response times and increase network communication traffic.
Finally, in many instances, a client can immediately begin using incremental data blocks before receiving the entire data block from the server. For example, in some multimedia applications, a client can begin to display incremental data blocks of an image before receiving the entire image. In current remote procedure call systems, however, the client waits until receiving the entire image before attempting to display the image. This leads to delays in using data. Furthermore, since current remote procedure call systems do not allow the use of incremental data blocks, these systems also waste computer memory since the memory cannot be freed for other uses until an entire block of data is received from the server.